LLMCloudHunter (Extração Automatizada de Regras de Detecção)

Nota da pasta de LLMs do capítulo 17, dedicada à automação do ciclo de CTI.
Apresenta o LLMCloudHunter, abordagem que converte relatos de CTI não estruturados sobre ameaças cloud em consultas de detecção para logs de AWS, Azure e GCP.
Dialoga com a nota de Sigma desta pasta, com o hunting em cloud e SaaS da seção 11 do capítulo 8 e com o mapeamento de lacunas do grupo MAP do framework CTH.

1. Contexto e Posicionamento na Biblioteca

Ambientes cloud concentram hoje grande parte da telemetria de segurança, mas os relatos de pesquisa que descrevem ameaças nesse ambiente são escritos em prosa: o pesquisador descreve o abuso do fluxo de trabalho do GitHub Actions, o roubo de token de metadados na AWS ou a criação de aplicativo malicioso no tenant do Azure, sem publicar a consulta que detectaria o comportamento. A lacuna entre o relato publicado e a regra de detecção operante é o espaço que o LLMCloudHunter ataca, automatizando a tradução de TTPs narradas em consultas executáveis sobre logs de cloud.

A nota ocupa posição de transição na pasta: herda do CTI-LLM o padrão de extração estruturada e antecipa a generalização para regras Sigma descrita na nota seguinte. A especialização em cloud não é detalhe, é a razão de existir da abordagem, porque os logs de AWS, Azure e GCP têm vocabulários de campo próprios, e é justamente esse mapeamento entre comportamento narrado e campo de log específico que exige o conhecimento embutido no modelo e nas instruções.

O ganho mensurável esperado do processo é tempo de implantação de detecção. No fluxo manual, o caminho do relato cloud até a consulta implantada leva dias ou semanas, dependendo da fila do time de detecção, porque exige leitura completa do relato, pesquisa de nomenclatura de eventos e escrita e teste da consulta. Com o pipeline automatizado assistido por revisor, o mesmo caminho encurta para horas, e a economia não vem de eliminar o revisor, vem de entregar ao revisor um pacote já estruturado com técnica, eventos e suposições, no lugar de uma página em branco.

2. O Problema da Conversão de TTPs em Consultas Cloud

Converter um relato em consulta de detecção exige mais do que extrair IOCs. É preciso reconhecer a técnica ATT&CK correspondente, saber quais serviços de log registram o comportamento, identificar os campos relevantes de cada provedor e escrever a lógica de filtro que separa o comportamento malicioso do ruído operacional legítimo. Em cloud, essa cadeia é mais longa que em endpoint, porque o mesmo comportamento pode aparecer em CloudTrail, Azure Activity Log ou audit log do G Suite com schemas completamente diferentes.

Três obstáculos específicos do ambiente cloud agravam o problema. Primeiro, a própria nomenclatura dos eventos é confusa, com nomes de operações como PutBucketPolicy ou UpdateAccountPasswordPolicy que exigem interpretação semântica, não correspondência literal. Segundo, o mesmo relato frequentemente mistura níveis de abstração, citando comando de CLI, chamada de API e evento de log para o mesmo passo do ataque. Terceiro, a cobertura de logging é opcional e configurável por região e serviço, de modo que uma consulta tecnicamente correta pode não ter dado para executar, e o processo precisa sinalizar essa condição em vez de simplesmente entregar a consulta.

3. Arquitetura da Abordagem e o Pipeline de Extração

O pipeline de referência recebe o relato em texto e devolve consultas candidatas validadas, organizado em estágios com responsabilidade única. A tabela abaixo descreve cada estágio com o insumo e o produto, e o bloco seguinte mostra o fluxo de execução.

Fluxo de execução (visão de alto nível)
1. Ingerir o relato e dividir em passos comportamentais com contexto local.
2. Para cada passo, classificar a técnica ATT&CK com evidência do texto.
3. Resolver a técnica para operações de API por provedor usando um
   dicionário curado de eventos (CloudTrail, Azure Activity, GCP audit).
4. Gerar a consulta no dialeto alvo (SPL, KQL, ou SQL do BigQuery).
5. Validar sintaxe e, quando houver amostra de log, validar semântica.
6. Devolver pacote com consulta, técnica, campos usados e suposições.
7. Encaminhar ao revisor humano e, aprovado, ao repositório de detecções.

O dicionário curado de eventos é o componente que mais distingue implementações boas de medíocres. O modelo conhece como o comportamento se chama em prosa, mas a correspondência exata de nome de operação, serviço e campo muda com frequência nos provedores, e dicionário versionado com entrada comentada por evento resolve essa instabilidade. Sem o dicionário, o modelo tenta lembrar nomes de operação de memória e erra sutilmente, gerando consulta que roda sem resultado por nome de campo errado.

O trecho abaixo ilustra o formato de entrada do dicionário para o estágio de resolução. Cada entrada fixa a técnica, os eventos por provedor e as observações de cobertura, e o prompt do estágio injeta somente as entradas relevantes às técnicas candidatas, mantendo o contexto curto e estável.

Entradas do dicionário curado (formato resumido)
T1098.001 | Additional Cloud Credentials
  AWS   : CreateAccessKey, UpdateAccessKey (IAM)
          obs: gestão de IAM loga na região de configuração global
  Azure : Add member to role (AzureAD), Update application - Password
          obs: requer diagnostic settings de AzureAD para o Log Analytics
  GCP   : iam.serviceAccountKeys.create, iam.serviceAccountKeys.enable
          obs: audit log de Admin Activity habilitado por padrão no projeto
T1530   | Data from Cloud Storage
  AWS   : GetObject (S3) ; alto volume, usar baseline por principal
  Azure : List KeyRings?; preferir StorageBlobLogs com operação Read
  GCP   : storage.objects.get ; considerar Data Access audit log (opcional)

4. Exemplo de Relato Publicado que Vira Consulta

O exemplo abaixo mostra a conversão de um passo típico de ataques cloud documentados publicamente, a criação de chave de acesso persistente por conta comprometida, desde o trecho de relato até a consulta final. O caso foi escolhido porque é comum, tem ruído operacional real e exige sinalizar suposição de cobertura.

Trecho do relato (não estruturado):
"Após comprometer as credenciais de um usuário IAM, o ator criou uma nova
chave de acesso para persistência e ativou uma chave de acesso existente
que estava inativa há meses, evitando criação de artefatos novos."

Processamento:
- Técnica candidata: T1098.001 Account Manipulation: Additional Cloud
  Credentials, evidência no trecho ("criou uma nova chave de acesso").
- Eventos CloudTrail relevantes: CreateAccessKey, UpdateAccessKey.
- Sinal de comportamento: UpdateAccessKey com Status=Active sobre chave
  inativa é o passo mais raro e de menor ruído operacional.

Consulta gerada (SPL, resumida):
index=cloudtrail sourcetype=aws:cloudtrail
  (eventName="CreateAccessKey" OR eventName="UpdateAccessKey")
  | search NOT useridentity.userName="*automation*"
  | eval age_days=coalesce(accessKey.age_days, -1)
  | where eventName="UpdateAccessKey" AND status="Active" AND age_days>30
    OR eventName="CreateAccessKey"
  | table _time, useridentity.userName, sourceIPAddress, eventName, status

Suposições registradas no pacote de saída:
- logging de CloudTrail de gestão IAM habilitado em todas as regiões;
- campo accessKey.age_days disponível por enriquecimento próprio;
- padrão "*automation*" cobre contas de provisionamento da organização.

O pacote de suposições é o que torna o artefato profissional. A consulta sem ele parece completa e não é, porque sem o enriquecimento de idade da chave a metade do caso de uso some, e sem a checagem de logging o time pode aprovar uma regra que nunca dispara por falta de dado. A lista de suposições vira checklist de implantação, e cada item marcado como não atendido vira requisito para o DAT.4 do framework CTH.

O mesmo comportamento no Azure ilustra a conversão entre provedores, com a consulta em KQL sobre o log de auditoria do Entra ID. A diferença estrutural é instrutiva: no Azure o evento equivalente registra criação e ativação de credencial de aplicativo, e o sinal raro passa a ser a exclusão de credencial antiga combinada com adição de nova pelo mesmo principal em janela curta, padrão de rotação forçada típico de tomada de conta.

Consulta equivalente (KQL sobre AuditLogs do Entra ID, resumida)
AuditLogs
| where OperationName has_any ("Update application - Certificates and
    secrets management", "Add service principal credentials")
| extend actor = tostring(initiatedBy.user.userPrincipalName)
| where result == "success"
| summarize cred_events=make_list(OperationName) by actor, bin(TimeGenerated, 10m)
| where array_length(cred_events) >= 2
| project TimeGenerated, actor, cred_events

5. Avaliação de Cobertura e Qualidade das Regras Geradas

Avaliar a abordagem exige responder duas perguntas separadas: quantos relatos produzem ao menos uma consulta plausível, e quantas consultas produzidas são de fato úteis. A primeira é a métrica de cobertura, medida sobre um conjunto de relatos rotulados por humano com o número de técnicas detectáveis esperadas. A segunda combina precisão sintática, taxa de consultas que parseiam, e utilidade prática, medida pela proporção de consultas que sobrevivem à revisão e entram no repositório de detecções.

O ensaio de falsos positivos é obrigatório e barato: rodar a consulta sobre 30 dias de histórico antes de aprovar dá o número de disparos esperado e as exceções legítimas a incluir. Consulta de evento raro como UpdateAccessKey sobre chave inativa dispara pouco, e o valor é alto. Consultas sobre eventos frequentes precisam de filtro adicional ou viram itens de hunting em vez de regras de alerta, e essa decisão pertence ao revisor humano com dados na mão.

6. Limitações da Abordagem

As limitações dividem-se entre as do método e as do material, e confundi-las gera expectativa errada. Do lado do método, o modelo não garante exaustividade, e um relato com dez técnicas pode gerar consultas para as sete mais descritas, com as três restantes apenas mencionadas. Do lado do material, relatos que descrevem o ataque só em nível de objetivo, sem ação observável, não produzem consulta de log por definição, e nenhum ajuste de prompt cria evento que o pesquisador não narrou.

• Comportamento legítimo idêntico ao malicioso: criação de chave de acesso é operação rotineira de provisionamento, e a consulta detecta o evento, não a intenção, exigindo contexto de linha de base ou horário para virar sinal.
• Dialeto e versão do provedor: nomes de campo e de evento mudam, e a consulta precisa de dono com cadência de revisão trimestral, como qualquer regra do catálogo.
• Relatos sem detalhe de execução: prosa estratégica não vira log, e o estágio de extração deve marcar essas técnicas como não resolvidas em vez de forçar consulta genérica.
• Dependência de logging habilitado: a regra melhor do mundo não compensa CloudTrail de gestão desligado, e a checagem de cobertura de log precede a aprovação de qualquer consulta.
• Custo de validação semântica: sem amostra de log representativa, a validação reduz-se à sintática, e a consulta entra no catálogo com selo de não testada em dados reais.

7. Erros Comuns e Pontos de Atenção

• Aprovar consulta por parecer de texto: a consulta que parece certa só é certa quando parseia e dispara contra dados reais, e o teste em histórico é a etapa que nenhum pacote pode pular.
• Gerar regra por IOC de relato cloud: endereço IP de ator em cloud muda de instância com facilidade, e a regra de valor mais duradouro é a de operação de API com contexto, não a de endereço literal.
• Ignorar multi-região: eventos de gestão aparecem na região configurada e não na região do ator, e consulta que filtra região específica perde eventos silenciosamente.
• Misturar tenants no prompt: relato de laboratório às vezes citando vários provedores no mesmo parágrafo exige separação por provedor antes do mapeamento de eventos, sob pena de consulta com campos de dois schemas.
• Tratar o dicionário de eventos como estático: provedores adicionam eventos todo trimestre, e o dicionário sem dono e sem cadência envelhece em silêncio, degradando a precisão do estágio de resolução.
• Acumular regras sem dono: consulta gerada automaticamente entra no catálogo com o mesmo rigor do grupo MAP do framework, com dono, técnica associada, data e revisão programada.

8. Integração com o Restante da Biblioteca

As consultas geradas alimentam o catálogo do grupo HNT e a análise de lacunas do grupo MAP, fechando o circuito entre relato público e cobertura mensurável de detecção cloud. O hunting em cloud da seção 11 do capítulo 8 fornece o repertório de fontes de log que o estágio de resolução assume, e a nota sobre ingestão e centralização de logs do controle DAT.4 define as condições que as suposições do pacote de saída verificam antes da aprovação.

Dentro da pasta, a nota generaliza o padrão iniciado pelo CTI-LLM e especializa o caminho que a nota de Sigma formaliza para endpoint e rede: a tríade extração, mapeamento e geração é a mesma, mudando o dicionário de eventos e o dialeto de saída. Lido em sequência, o capítulo 17 apresenta primeiro o modelo especializado, depois a decomposição em agentes para enriquecimento, e por fim os dois padrões de conversão de inteligência em detecção, cloud e Sigma, preparando o leitor para a pasta de agentes autônomos, onde essas capacidades passam a ser orquestradas em loop de decisão.