Bounty Hunter (Emulação Autônoma de Adversários Multi-Facetados)

Nota de encerramento da pasta de agentes autônomos do capítulo 17, no lado ofensivo da defesa.
Apresenta o Bounty Hunter, framework de agentes que emulam de forma autônoma perfis de adversários distintos e competem para vencer as detecções do ambiente alvo.
Dialoga com as notas de iThelma e agentic AI desta pasta, com a emulação de adversários do controle SIM.2 e com a medição de cobertura do SIM.5 do framework CTH.

1. Contexto e Posicionamento na Biblioteca

As emulações de adversário do grupo SIM dependem de planejamento humano extensivo: escolher o ator, mapear as TTPs, montar a campanha no Caldera ou plataforma equivalente, executar e avaliar. O Bounty Hunter propõe inverter a carga: agentes autônomos recebem perfis de adversário descritos por TTPs e objetivos, planejam campanhas por conta própria, executam as ações contra um ambiente de teste e competem entre si e contra as detecções implantadas. O valor para o defensor é a exposição de lacunas de detecção e de caminhos de ataque que o planejamento manual raramente combina.

A posição na biblioteca fecha o arco do capítulo 17: as notas de CTI automatizaram a inteligência, o iThelma automatizou a caça e a arquitetura agêntica organizou os componentes, e agora a mesma engenharia é apontada para o próprio ambiente defensivo, emulando quem o ataca. A nota exige leitura prévia do controle SIM.2 e da medição de cobertura do SIM.5, porque os resultados da emulação só viram melhoria quando entram no mesmo circuito de medição de cobertura das simulações tradicionais.

A diferença para o BAS tradicional é de geração, e não de detalhe. O BAS executa cenários desenhados por humano, com passos fixos e resultado previsível, e mede se a regra disparou para o passo conhecido. A emulação agêntica decide os passos, combina técnicas de formas não previstas pelo time que montou o exercício e adapta a rota quando encontra bloqueio, aproximando-se do que um adversário real faz de improvisação. O custo dessa riqueza é imprevisibilidade de resultado, e por isso o ambiente de teste, o árbitro e a governança da rodada têm que estar muito mais bem definidos do que no BAS clássico.

2. Emulação Multi-Facetada: Perfis de Ator Competindo

O atributo multi-facetado é o diferencial do desenho. Em vez de uma campanha única planejada por humano, o framework executa em paralelo agentes com perfis de adversário distintos, cada um com objetivos, apetite de risco, ferramentas preferidas e restrições de opsec próprios, derivados de relatos públicos e do catálogo ATT&CK. Os agentes não colaboram: competem pela pontuação, e a competição é o mecanismo que gera diversidade de caminhos, porque o mesmo objetivo alcançado por rota já explorada vale menos que rota nova.

A competição entre perfis produz um efeito de cobertura difícil de obter com campanha única: o ambiente é testado simultaneamente por um ator barulhento de ransomware, por um intruso silencioso de espionagem e por um facilitador de acesso inicial, e as lacunas que sobrevivem a todos os perfis são as lacunas reais do ambiente. Perfis diferentes testam superfícies diferentes, e a comparação entre os caminhos que cada perfil encontrou é informação de primeira ordem para o time de detecção.

Essa comparação tem leitura gerencial direta, e não apenas técnica. Quando o perfil barulhento é detectado e contido enquanto o silencioso passa livre, o problema prioritário é de visibilidade sobre ações discretas, e o investimento aponta para telemetria de identidade e de processo. Quando todos os perfis são detectados mas nenhum é impedido, o problema é de resposta, e a prioridade migra para o AUT.5. A emulação multi-facetada entrega, portanto, não apenas a lista de lacunas, mas a priorização entre tipos de investimento defensivo que o relatório executivo do grupo MET precisa para justificar orçamento.

3. Arquitetura Multi-Agente do Framework

A arquitetura separa os papéis do lado adversário dos papéis de árbitro e recompensa, e segue o mesmo vocabulário de planejador, executor e crítico das notas defensivas da pasta. A tabela abaixo descreve os componentes com a responsabilidade central de cada um, e o bloco seguinte mostra o fluxo de uma rodada de emulação.

Fluxo de uma rodada de emulação (resumido)
1. Perfilador emite o dossiê do adversário para a rodada.
2. Agente atacante decompõe o objetivo em campanha com etapas ATT&CK.
3. Crítico de opsec valida cada etapa contra o dossiê; ações fora do
   perfil são substituídas antes da execução.
4. Executor aplica as ações no ambiente de teste isolado.
5. Árbitro compara cada evento com o catálogo de detecções e registra
   detecção, miss ou lacuna.
6. Avaliador pontua os agentes por objetivo alcançado, furtividade e
   novidade de caminho, e emite o relatório da rodada.
7. Resultados alimentam o backlog de detecções e a próxima rodada.

O ponto de engenharia mais sensível é o crítico de opsec, que impede o que tornaria a emulação inútil ou perigosa: ações fora do perfil que produzem ruído não comparável, e ações que escapam do ambiente de teste. A execução acontece em ambiente isolado por desenho, com controles de saída de rede equivalentes aos do BAS tradicional, e o dossiê versionado do perfilador garante que o resultado de cada rodada seja reproduzível para auditoria, requisito da mesma natureza que o transcript do iThelma no lado defensivo.

A diferenciação dos perfis exige cuidado com o dossiê, porque perfil mal especificado produz agente genérico que joga igual aos demais, e a competição perde o valor de cobertura. Cada dossiê traz as TTPs preferenciais com peso, as TTPs proibidas, o apetite de ruído em termos objetivos, por exemplo, número máximo de eventos de alerta aceitáveis, e as condições de sucesso por etapa. A tabela abaixo resume como cada campo do dossiê se traduz em comportamento observável do agente na rodada.

4. Exemplo de Cenário com Dois Perfis de Ator

O cenário abaixo emula o mesmo objetivo, acesso a dados de arquivo corporativo, por dois perfis diferentes, um operador de ransomware barulhento e um intruso de espionagem silencioso. A comparação dos resultados mostra por que perfis competindo valem mais que uma campanha única.

Rodada 42, ambiente de teste isolado, objetivo: acessar arquivo crítico

Perfil A (operador de ransomware, ruído tolerado)
- phishing com anexo macro para estação de usuário (T1566.001)
- execução de loader e desativação de proteção local (T1562.001)
- descoberta de compartimentos com listagem ampla (T1135)
- acesso ao arquivo via compartimento administrativo (T1021)
Resultado: objetivo alcançado em 6 etapas; 3 detecções disparadas
   (phishing por e-mail, desativação de proteção, varredura de rede);
   3 etapas sem detecção, incluindo o acesso final ao compartimento.

Perfil B (intruso de espionagem, opsec restrita)
- credencial obtida de repositório interno de código (T1552.001)
- uso de ferramenta de administração nativa com nome alterado (T1036.005)
- movimento lateral via serviço remoto com credencial válida (T1021.002)
- leitura do arquivo com acesso mínimo e sem escrita (T1005)
Resultado: objetivo alcançado em 4 etapas; 0 detecções disparadas;
   trilha completa em eventos de log, sem regra associada a nenhuma
   etapa, o que configura lacuna de cobertura e não de telemetria.

A leitura defensiva do cenário é direta e vale a pontuação da rodada. O perfil A foi detectado cedo e ainda assim alcançou o objetivo, o que indica que as detecções disparam mas não bloqueiam nem correlacionam, problema de resposta e não de regra. O perfil B venceu a rodada com pontuação máxima e zero detecção, expondo que a cadeia inteira de uso de ferramenta nativa com máscara de nome não tem cobertura, e essa lacuna, agora evidenciada por replay com trilha em log, entra no backlog de detecções com as consultas candidatas já associadas a cada etapa.

A pontuação da rodada é calculada pelo árbitro com regra fixa e publicada no relatório, e o exemplo abaixo mostra o placar resumido dos dois perfis, formato que o programa deve manter para permitir comparação entre rodadas e evolução da cobertura ao longo do tempo.

Placar da rodada 42 (resumido)
Perfil A: objetivo SIM, 6 etapas, 3 detecções, 3 lacunas
          pontos: objetivo 100, furtividade 50, novidade 70, total 220
Perfil B: objetivo SIM, 4 etapas, 0 detecções, 0 bloqueios
          pontos: objetivo 100, furtividade 100, novidade 90, total 290
Vencedor: perfil B
Lacunas para backlog: T1552.001 sem regra, T1036.005 sem regra,
   T1021.002 sem regra, T1005 sem regra, correlação de cadeia ausente
Telemetria: trilha completa em log para todas as etapas dos dois perfis,
   o que classifica todas as lacunas como de detecção, e não de coleta.

5. Métricas de Avaliação da Emulação

As métricas dividem-se entre as que pontuam os agentes adversários e as que medem a qualidade do ambiente defensivo testado, e as duas famílias precisam ser reportadas juntas para a emulação ter valor. A tabela abaixo consolida o painel de referência, com o consumidor indicado de cada métrica.

A métrica de novidade de caminho é o que mantém a emulação útil ao longo do tempo. Sem penalidade de repetição, os agentes convergem para a rota que funcionou na primeira rodada e a suíte degrada em teste de regressão disfarçado, valioso, mas não exploratório. Com a penalidade calibrada, cada rodada pressiona rotas alternativas, e a curva de lacunas descobertas por rodada se torna o indicador de esgotamento do exercício: quando as rodadas param de produzir lacunas novas, o ambiente está coberto para os perfis testados, e o esforço migra para perfis novos.

A cadência de rodadas completa o desenho de avaliação. A prática de referência combina rodadas mensais exploratórias, com perfis variados e penalidade de novidade ativa, com rodadas de regressão trimestrais, que repetem dossiês fixos para verificar que as correções implantadas não regrediram e que a cobertura se manteve. As duas cadências produzem séries históricas distintas e complementares, e o relatório executivo do programa se alimenta das duas: a exploratória mostra onde o ambiente ainda falha, a regressão mostra se o que foi corrigido permanece corrigido.

6. Limitações e Limites Éticos

A emulação autônoma herda as limitações do BAS e acrescenta as próprias. Os agentes operam sobre perfis simplificados, e o adversário real improvisa com ferramenta inédita, alvo diferente e tolerância de ruído que nenhum dossiê captura por completo. O repertório de técnicas vem do público, e técnicas de dia zero ou de exploração específica do ambiente escapam por definição, de modo que lacuna não encontrada pela emulação não é garantia de ausência de lacuna, e o relatório precisa dizer isso com clareza para não criar falsa segurança na liderança.

• Ambiente exclusivo de teste: emulação autônoma roda apenas em ambiente isolado e contratado para esse fim, nunca em produção, e o isolamento é verificado antes de cada rodada, não presumido.
• Autorização formal por rodada: o exercício tem dono, janela e escopo aprovados, mesmo sendo simulado, porque a distinção entre emulação e ataque real é processual e precisa estar documentada.
• Sem dados reais de cliente: o ambiente de teste usa dados sintéticos ou anonimizados, e nenhum artefato da emulação pode conter informação de produção, alinhando o exercício às regras de confidencialidade do TLP.
• Perfis sem named actors como acusação: o dossiê descreve comportamento e TTPs, e relatório de lacuna não vira atribuição de ameaça, matéria tratada com as limitações próprias da seção 02 do capítulo 5.
• Resultados no circuito defensivo: toda lacuna encontrada tem dono e prazo, porque exercício que expõe lacuna sem backlog vira risco documentado sem remediação, pior que não exercitar.
• Proibição de monetização ou publicação antecipada: achados seguem o canal interno acordado, e publicação externa de lacuna antes da correção viola a responsabilidade que o exercício pressupõe.
• Agentes com repertório ofensivo real em texto de instrução: os dossiês descrevem comportamento em nível de TTP e não receitas de execução, e o controle de conteúdo do dossiê segue a mesma disciplina de manuseio que qualquer material sensível do programa.
• Assumir que lacuna fechada permanece fechada: a regressão trimestral existe exatamente porque mudanças de ambiente reabrem lacunas, e o relatório de rodada única nunca deve ser lido como estado permanente da cobertura.

7. Integração com o Restante da Biblioteca

Os resultados do Bounty Hunter entram no mesmo circuito de medição do SIM.5, com as lacunas confirmadas alimentando a análise do grupo MAP e o backlog de detecções governado pelo AUT.3, e as consultas candidatas por etapa seguem o padrão de validação descrito na nota de Sigma da pasta anterior. O ciclo fecha com o hunting: as trilhas de log das rodadas são datasets de avaliação prontos para o iThelma, que pode caçar com veredito de terra conhecido, unindo os dois lados da pasta em um único circuito de melhoria.

A leitura de encerramento do capítulo é a simetria entre as duas pastas. Do lado da CTI, agentes estruturam texto de ameaça em inteligência verificada e regras de detecção; do lado do hunting, agentes executam caça com supervisão humana e adversários emulados testam o resultado. Em todos os desenhos apresentados, o padrão de qualidade é o mesmo: trilha auditável por passo, crítico independente do executor, guardrail por classe de ação e humano responsável pelas decisões de efeito persistente, e é por esse padrão que qualquer proposta agêntica que chegue ao mercado deve ser avaliada.

O próximo passo natural de estudo é a leitura cruzada deste capítulo com os grupos SIM e MET do framework CTH, porque é lá que os resultados de automação e emulação se convertem em métrica de programa e em argumento de orçamento. O capítulo 17 entrega as capacidades, e os grupos 12 e 16 do framework entregam a prova de que a capacidade mudou a cobertura, o dwell time e o custo por descoberta, que são os números que sobrevivem ao entusiasmo da tecnologia e sustentam o programa no longo prazo.