Extração Automatizada de TTPs e Geração de Regras Sigma via LLM

Nota da pasta de LLMs do capítulo 17, dedicada à automação do ciclo de CTI.
Formaliza o padrão geral de conversão de relatos de CTI em regras Sigma por meio de LLMs, com chain-of-thought, saída em schema JSON, validação por testes automatizados e loop humano.
Dialoga com as notas de CTI-LLM e LLMCloudHunter desta pasta e com as consultas e linguagens da seção 03 do capítulo 9.

1. Contexto e Posicionamento na Biblioteca

Enquanto a nota anterior especializa a conversão de inteligência em detecção para o ambiente cloud, esta nota consolida o padrão geral aplicável a endpoint, rede e identidade, no formato Sigma. Sigma é o padrão aberto de descrição de detecções adotado pela comunidade e tratado na nota de consultas e linguagens da seção 03 do capítulo 9, e sua estrutura declarativa, com seleção, condição e metadados, torna-se o alvo natural de geração por modelo de linguagem, porque o JSON resultante é verificável por schema e traduzível para SIEMs distintos.

O valor de padronizar o padrão, e não apenas um caso, é que o mesmo desenho de pipeline serve para relato de ransomware que descreve a exclusão de sombras de cópia, para post de pesquisa que narra a abuso de ferramenta de administração remota e para aviso de fornecedor que documenta exploração de CVE com comandos de exemplo. Variando o schema de saída e a suíte de validação, o mesmo esqueleto de prompt e os mesmos controles de qualidade cobrem o catálogo inteiro de detecções do programa.

2. O Padrão Geral: Do Relato à Regra

O padrão se organiza em quatro movimentos, cada um com controle de qualidade próprio. Extração transforma o texto em fatos estruturados, mapeamento fixa as técnicas ATT&CK correspondentes, geração produz o YAML Sigma a partir dos fatos e validação decide se a regra entra no catálogo. A separação entre geração e validação é o princípio estruturante: o modelo gera, mas quem aprova é um processo com testes objetivos, e não a percepção de plausibilidade do texto gerado.

O desenho assume que nem todo relato merece regra. Relatos que só trazem IOCs de rede são atendidos pelo fluxo de enriquecimento da pasta, e relatos puramente estratégicos não têm evento de log correspondente. O estágio de extração deve marcar explicitamente o caso de não detectabilidade, devolvendo ao processo a decisão documentada de não gerar regra, em vez de produzir regra genérica que dispara para tudo.

3. Chain-of-Thought e Saída Estruturada com Schema

O uso de chain-of-thought, isto é, pedir ao modelo que raciocine em passos antes de responder, melhora o mapeamento de técnicas porque força a decomposição do relato em comportamentos antes de atribuir IDs. A prática recomendada separa o raciocínio da resposta final: o modelo pode pensar em passos internos, mas a saída entregue ao pipeline é exclusivamente o JSON do schema, sem prosa, o que simplifica a validação e impede que o raciocínio vire o artefato consumido.

O schema abaixo define o contrato entre geração e validação. Campos obrigatórios com evidência, valores de eventos explícitos e seleção Sigma declarada como estrutura, e não como texto livre, reduzem a margem de erro para o que a validação consegue verificar automaticamente.

Schema JSON de saída (resumo)
{
  "document": {"source_title": "", "source_url": "", "tlp": "amber"},
  "behaviors": [{
     "description": "",            // o que o ator faz
     "evidence": "",               // frase de origem no relato
     "attck_id": "",               // técnica ou subtécnica
     "platform": "windows|linux|macos|iaas|azuread|office365",
     "log_source": "",             // ex.: Sysmon, Security 4688, CloudTrail
     "event_fields": [{"field": "", "value": ""}],
     "sigma_selection": {"selector": "", "values": {}},
     "conditions_notes": ""        // exceções legítimas previstas
  }],
  "non_detectable": [{"description": "", "reason": ""}]
}

Regras do schema:
- behaviors e non_detectable são obrigatórios, ainda que vazios;
- todo behavior exige evidence não vazia;
- attck_id segue o formato T + 4 dígitos, com ponto e dígito para subtécnica;
- sigma_selection usa apenas seletores válidos do Sigma (Title, Status,
  Detection, Logsource, Falsepositives, Tags, References).

A escolha da plataforma e da fonte de log é o campo mais sensível do schema, porque define onde a regra pode existir. O prompt instrui o modelo a recusar fonte de log que o relato não sustenta, e o validador confere a coerência entre plataforma declarada e seleção usada, rejeitando combinações impossíveis como categoria process_creation sobre logs de firewall. Esse tipo de erro é frequente em geração ingênua e é exatamente o que o schema estrito com verificação automática elimina cedo.

4. Exemplo de Prompt com Schema e Saída

O exemplo abaixo percorre um caso típico, o relato de uma técnica de defesa evasiva descrita em texto, com o prompt de sistema, o trecho do relato e a saída JSON esperada. A regra Sigma final e o resultado da validação aparecem na seção seguinte.

Sistema: você é um gerador de detecções a partir de CTI. Siga o schema
fornecido. Para cada comportamento: (1) descreva o ato em uma frase;
(2) cite a evidence exata; (3) mapeie a técnica ATT&CK mais específica;
(4) escolha a fonte de log que registra o ato; (5) declare a seleção Sigma.
Se um comportamento não deixa rastro em log conhecido, mova-o para
non_detectable com reason. Não invente campos nem valores ausentes no texto.

Usuário (trecho do relato):
"O operador renomeou o binário legítimo do Windows para um caminho de sistema
e o executou via WMI para parecer telemetria normal, seguido da criação de
uma tarefa agendada com nome de serviço falso para persistência."

Saída esperada (resumida):
{
  "behaviors": [
    {"description": "Execução de binário renomeado via WMI",
     "evidence": "renomeou o binário legítimo ... e o executou via WMI",
     "attck_id": "T1036.005", "platform": "windows",
     "log_source": "Sysmon EventID 1",
     "event_fields": [
        {"field": "Image", "value": "caminho de sistema com nome incoerente"},
        {"field": "ParentImage", "value": "WmiPrvSE.exe"}],
     "sigma_selection": {"selector": "Image|endswith",
        "values": {"Image": "\\svchost.exe", "ParentImage": "WmiPrvSE.exe"}},
     "conditions_notes": "excluir hosts de imagem padrão validada"},
    {"description": "Persistência via tarefa agendada com nome de serviço",
     "evidence": "criação de uma tarefa agendada com nome de serviço falso",
     "attck_id": "T1053.005", "platform": "windows",
     "log_source": "Security EventID 4698",
     "event_fields": [{"field": "TaskName", "value": "nome de serviço falso"}],
     "sigma_selection": {"selector": "TaskName|contains",
        "values": {"TaskName": "Service"}},
     "conditions_notes": "ajustar por lista de tarefas legítimas"},
  ],
  "non_detectable": []
}

A saída ilustra dois comportamentos detectáveis e nenhum caso de não detectabilidade, mas o prompt exige que o campo venha preenchido quando houver, e a presença do campo vazio explícito permite ao validador distinguir ausência verificada de omissão do modelo. Note também que a seleção da regra de masquerading usa a combinação de imagem e processo pai, e não apenas o nome do binário, porque nome de sistema executado de caminho incoerente é o sinal, e o prompt instrui o modelo a preferir seleções combinadas quando o relato sustenta.

5. Validação por Testes Automatizados e Loop Humano

A validação automatizada aplica uma bateria objetiva a cada regra candidata antes de qualquer revisão humana, e a regra que falha volta ao estágio de geração com o erro anexado, formando o loop automático de correção. A bateria inclui verificação de schema YAML e de campos Sigma obrigatórios, conferência de coerência entre logsource e seleção, compilação da regra para o dialeto do SIEM de destino e execução em corpora de teste com amostras rotuladas de eventos benignos e, quando disponíveis, de emulações da técnica geradas com Atomic Red Team.

O corpus de emulação merece organização permanente: cada técnica coberta pelo programa tem um caso Atomic Red Team correspondente executado em laboratório, com os eventos resultantes gravados como amostra de teste. Com esse acervo, a validação deixa de depender de coincidência temporal e vira teste de regressão executável a cada nova versão de prompt ou de modelo, o mesmo espírito da suíte descrita na nota de CTI-LLM.

O loop humano fecha o processo onde a máquina não alcança. O revisor julga o valor da regra, define se vira alerta ou item de hunting, ajusta exceções legítimas específicas do ambiente e aprova a entrada no catálogo com dono e data. A regra aprovada volta ao corpus de treino como exemplo positivo revisado, e a regra rejeitada com motivo anotado vira exemplo negativo, transformando cada decisão de revisão em dado de melhoria do ciclo seguinte. É esse fechamento, e não o prompt, o que separa uma linha de produção de detecção madura de uma demonstração pontual.

6. Métricas de Qualidade: Precisão, Cobertura e Falsos Positivos

As três métricas centrais avaliam dimensões distintas e devem ser reportadas juntas. Precisão mede a proporção de regras geradas que sobrevivem à revisão sem alteração estrutural. Cobertura mede a proporção de comportamentos detectáveis do relato que receberam regra válida. Falsos positivos medem o custo operacional das regras aprovadas, contado em disparos por mil eventos sobre corpus benigno. O painel abaixo sugere limiares de partida para um programa em construção, valores a calibrar com o baseline próprio.

O acompanhamento das métricas segue a mesma disciplina de qualquer pipeline do framework: cada regra carrega o envelope com versão de prompt, versão de modelo e resultado da bateria de testes, e o painel agrega por versão. Quando uma nova versão do gerador entra em avaliação, os relatos de uma amostra fixa de teste passam pelas duas versões e o comparativo de precisão, cobertura e falsos positivos decide a promoção, o que impede que a melhoria percebida de um prompt recém-editado substitua um processo medido sem evidência.

A taxa de não detectabilidade é a métrica menos intuitiva e das mais importantes. Marcar corretamente que um comportamento não deixa rastro em log conhecido é uma afirmação de conhecimento do domínio, e taxa alta de marcação correta indica que o processo reconhece os limites da telemetria em vez de forçar regras improdutivas. Taxa próxima de zero em relatos complexos é sinal de alerta, não de sucesso, porque nenhum relato técnico de campanha real é inteiramente detectável por log de evento.

7. Erros Comuns e Pontos de Atenção

• Gerar regra a partir de IOC de arquivo: hash e nome de binário descrito no relato viram busca de Intel, não regra Sigma, e confundir os dois enche o catálogo de regras que envelhecem em semanas.
• Aceitar seleção muito ampla: a regra de TaskName contendo a palavra Service do exemplo dispararia em ambiente real com frequência inaceitável, e o corpus benigno da validação existe justamente para capturar esse tipo de erro antes da aprovação.
• Pular o loop de retorno ao gerador: devolver o erro de compilação ao modelo com contexto é mais barato que corrigir à mão, e a correção manual sem retorno esconde o defeito do processo em vez de eliminá-lo.
• Misturar relatos de provedores diferentes no mesmo prompt: contexto cruzado induce o modelo a combinar campos de schemas distintos, e o pipeline deve processar um documento por vez.
• Tratar Tags ATT&CK da regra como mapeamento oficial: as tags orientam a navegação no catálogo, e o mapeamento de cobertura do grupo MAP continua vindo do processo estruturado de análise de lacunas.
• Esquecer a cadência de revisão: regra gerada automaticamente envelhece como qualquer outra, e o catálogo precisa da mesma governança de dono e data descrita no controle AUT.3 do framework CTH.
• Publicar métrica de cobertura sem denominador: cobertura de 90% sobre três comportamentos detectáveis é menos informativa que 60% sobre vinte, e o denominador do relato faz parte da métrica.

8. Integração com o Restante da Biblioteca

As regras aprovadas entram no catálogo governado pelo controle AUT.3 do framework CTH, alimentam o heatmap de cobertura do grupo MAP e disputam prioridade na fila de hunting do grupo HNT quando o falso positivo previsto não cabe em alerta. A conversão de regras Sigma para o dialeto do SIEM segue o mesmo caminho da nota de consultas e linguagens da seção 03 do capítulo 9, e os casos de emulação do Atomic Red Team conectam a validação desta nota com a simulação de ataques do grupo SIM.

Dentro do capítulo, esta nota fecha a sequência de LLMs para CTI com o padrão generalista que as notas anteriores especializaram: CTI-LLM forneceu o modelo de base para extração, IntelForge garantiu a qualidade do indicador com verificação independente, LLMCloudHunter adaptou o mapeamento ao vocabulário dos logs cloud, e aqui o ciclo completo extração, geração e validação aparece de forma reutilizável. A pasta de agentes autônomos que segue assume esse repertório e o coloca em movimento, com um agente que planeja e executa iterações de hunting sobre o SIEM e a EDR sem prompt único pré-desenhado.