CAIRN Toolkit (Rastreamento de Malware Integrado com IA)

Nota do Capítulo 17, pasta de AI-Orchestrated Attacks (Ameaças com IA).
Apresenta o CAIRN, toolkit público de pesquisa para identificar malware potencialmente desenvolvido com apoio de IA generativa, com sinais de código, pontuação e correlação entre amostras.
Dialoga com as notas de Campanha Anthropic e de FAMOUS CHOLLIMA da mesma pasta e com a análise de malware e de campanhas dos capítulos 5 e 9.

1. Contexto e Posicionamento na Biblioteca

A biblioteca dedicou o capítulo 5 à análise de campanhas e ao clustering de amostras, e o capítulo 9 às ferramentas de análise, sempre sob a premissa de que o malware é escrito por humanos com estilos identificáveis. Esta nota registra o ajuste que a IA generativa impõe a essa premissa: uma parte crescente do código ofensivo é gerada ou assistida por LLMs, o que cria padrões de escrita novos, comuns a amostras de autores diferentes, e ao mesmo tempo rastreáveis. O CAIRN, toolkit público lançado como projeto de pesquisa em 2025, é a primeira iniciativa amplamente conhecida a tratar essa questão de forma estruturada, com o objetivo declarado de ajudar a comunidade a identificar e acompanhar malware potencialmente assistido por IA.

O posicionamento na biblioteca é o de instrumento do analista de CTI técnico. O CAIRN não substitui desassembly, sandbox nem análise de infraestrutura, ele acrescenta uma dimensão de proveniência à análise: o artefato mostra sinais de ter sido gerado por modelo, e essa informação muda como o analista agrupa campanhas, estima a maturidade do ator e interpreta a velocidade de evolução do código. A nota descreve como o toolkit funciona, quais sinais examina, como usar em fluxo de análise e, com igual peso, quais limitações de atribuição o analista precisa respeitar.

2. O Problema: Identificar Desenvolvimento Assistido por IA em Malware

A pergunta que motiva o toolkit tem consequências analíticas diretas. Se uma família de malware que antes mudava a cada trimestre passa a mudar a cada semana, com refatorações consistentes e documentação uniforme, a hipótese de desenvolvimento assistido por IA altera a avaliação de capacidade do ator, a estimativa de tempo de resposta do defensor e a prioridade da ameaça. Se, por outro lado, dois agrupamentos de amostras de famílias distintas compartilham o mesmo conjunto de sinais de geração, existe a possibilidade de que ambos usem a mesma ferramenta ou o mesmo fluxo de produção, e essa pista agrega o que a infraestrutura sozinha não agregaria.

O problema é difícil por três razões técnicas. Código gerado por LLM pode ser editado por humanos depois, diluindo sinais. Sinais de estilo são probabilísticos, e código legítimo contemporâneo também é cada vez mais escrito com assistentes de código, o que produz falsos positivos se o sinal for usado isoladamente. E a ausência de sinal não prova ausência de uso de IA, porque modelos diferentes produzem estilos diferentes e o corpus de referência é sempre parcial. O CAIRN ataca o problema com transparência: publica os sinais que usa, mantém corpus de referência e trata o resultado como pontuação de similaridade, e não como veredito. A hipótese de desenvolvimento assistido não é curiosidade de laboratório, ela muda decisões de priorização, de estimativa de risco e de vida útil de detecção. A tabela abaixo organiza as perguntas analíticas que essa hipótese ajuda a responder. Cada linha deve ser lida como ponte entre um dado técnico da amostra e uma decisão de inteligência.

3. Como o Toolkit Funciona

O funcionamento do CAIRN segue três etapas conceituais. Na primeira, o analista fornece artefatos, tipicamente código-fonte recuperado em campanhas, amostras de malware em linguagens interpretadas ou decompilados com legibilidade suficiente. Na segunda, o toolkit extrai do artefato um conjunto de características de estilo e estrutura, compara com o corpus de referência de código gerado por IA e de código humano, e produz uma pontuação de similaridade com geração por IA, acompanhada da lista de sinais que sustentam a pontuação. Na terceira, os resultados podem ser comparados entre amostras, permitindo agrupar artefatos que compartilham a mesma assinatura de geração e acompanhar como essa assinatura muda ao longo do tempo, inclusive quando o ator troca de modelo ou ajusta o fluxo.

A decisão de design mais importante para o uso em CTI é a separação entre pontuação e sinais. A pontuação sozinha é uma pista, e a lista de sinais é o que permite ao analista avaliar se a pista faz sentido no contexto, por exemplo, quando o sinal dominante é comentário de API que não existe, o analista sabe que modelos alucinam interfaces, e quando o sinal dominante é formatação uniforme demais, o analista sabe que o mesmo sinal aparece em código corporativo escrito com assistente legítimo. O toolkit fornece evidência estruturada, e a interpretação permanece com o analista, na mesma divisão de trabalho que a biblioteca defende para toda automação analítica.

4. Características Extraídas e Corpus de Referência

A análise interna do toolkit pode ser descrita como extração de características em quatro camadas complementares. A camada lexical observa vocabulário, densidade de comentários e padrões de nomes. A camada estrutural observa organização de funções, cabeçalhos, tratamento de erro e blocos utilitários. A camada semântica observa coerência entre lógica e documentação, incluindo chamadas de API que não existem. A camada de similaridade compara a representação vetorial do artefato com as representações do corpus de referência e produz a pontuação final.

O corpus de referência é o componente vivo do sistema, e entender sua composição evita leitura ingênua da pontuação. O corpus combina código gerado por modelos conhecidos, código humano em contextos comparáveis e código ofensivo de referência, e a distribuição desse material muda com cada versão do toolkit. Para o analista, isso significa duas regras práticas: registrar a versão do toolkit junto à pontuação, e tratar mudança de versão como evento de recalibração para comparações longitudinais.

5. Sinais Típicos de Código Gerado por GenAI

A tabela abaixo consolida os sinais que o CAIRN e a literatura correlata associam a código gerado por IA generativa. A coluna de risco de falso positivo é essencial, porque nenhum sinal é exclusivo de código ofensivo gerado por IA.

A leitura analítica correta é conjuntural. Um sinal isolado vale pouco, três sinais de grupos diferentes, como alucinação de API somada a boilerplate idêntico e comentariado uniforme, elevam a confiança na hipótese de geração assistida. E a presença do sinal informa sobre o processo de produção, nunca sobre a autoria final, distinção que a seção de limitações de atribuição desenvolve.

6. Exemplo de Saída e Interpretação de Pontuação

O bloco abaixo ilustra, em formato didático, o tipo de saída que o fluxo de análise registra para cada artefato, com pontuação, sinais ativos e trechos de sustentação. O exemplo é hipotético e serve de gabarito para o campo de proveniência do relatório tático, com os mesmos campos independentes do toolkit usado. A estrutura também facilita a ingestão automatizada na plataforma de CTI.

{
  "amostra": "loader_x_2025-08-12",
  "ferramenta": "CAIRN",
  "versao_toolkit": "2025.11",
  "pontuacao_similaridade_ia": 0.83,
  "sinais_ativos": [
    {"sinal": "chamada_de_api_inexistente", "trecho": "net::post_multipart_v2(...)", "peso": "alto"},
    {"sinal": "comentariado_uniforme", "densidade": "alta", "peso": "medio"},
    {"sinal": "boilerplate_igual", "referencia": "loader_b_2025-03", "peso": "medio"}
  ],
  "confianca_provisoria": "moderada",
  "justificativa": "alucinacao de API indicada, sem confirmacao por revisao de biblioteca; dois sinais estruturais"
}

A leitura da saída segue a regra da pontuação com sinais. A pontuação de 0,83 sozinha não sustenta conclusão, e é o conjunto, alucinação de API com peso alto somada a dois sinais estruturais, que eleva a hipótese a confiança moderada. A justificativa escrita antes da divulgação é o que protege o relatório em revisão por pares, porque obriga o analista a nomear qual evidência sustenta cada nível de confiança.

7. Correlação com Campanhas e Uso em CTI

O uso de maior valor em CTI é o de correlação longitudinal. Ao registrar a assinatura de geração de cada amostra no repositório de campanhas, o time cria uma dimensão nova no Diamond Model, a dimensão de capacidade de produção, e passa a responder perguntas que antes não tinham evidência. A troca repentina de assinatura entre uma campanha e a seguinte pode indicar troca de modelo ou de ferramenta de fluxo de trabalho. A estabilidade da assinatura por muitos meses indica fluxo produtivo consolidado. A convergência de assinaturas entre famílias distintas sugere compartilhamento de ferramental, a mesma pista que o agrupamento de infraestrutura fornece no plano de rede, agora no plano de produção de código. O exemplo abaixo mostra como a dimensão longitudinal se materializa no repositório de campanhas. As linhas são hipotéticas, e o que importa é o padrão de leitura: assinatura estável, troca abrupta e convergência entre famílias são três configurações com três interpretações distintas. O formato replica o registro de infraestrutura por onda, aplicado à dimensão de produção.

O padrão de troca na onda 3 pede cuidado redobrado, porque pode significar tanto evolução natural do ator quanto tentativa deliberada de quebrar correlação após exposição pública. A convergência com a família B vira hipótese de compartilhamento de ferramental, que a infraestrutura e os TTPs podem confirmar ou refutar. A família C, por sua vez, lembra que ausência de sinal é informação incompleta, nunca exoneração.

Para o analista de CTI técnico do dia a dia, o uso direto é responder a pergunta do dossiê de amostra: o malware analisado mostra sinais de desenvolvimento assistido por IA, com qual pontuação e quais sinais. A resposta entra no relatório tático como campo de proveniência, ao lado das plataformas afetadas e das técnicas ATT&CK, e alimenta a avaliação de capacidade do ator no relatório estratégico. Para o gerente de detecções, a informação tem uso operacional adicional: malware produzido em volume com assistência de IA tende a variar mais rápido, e a regra estática de byte exato envelhece mais rápido, o que orienta priorizar detecção comportamental sobre IOC frágil.

8. Limitações de Atribuição

As limitações de atribuição são o ponto onde o uso do CAIRN mais precisa de disciplina. Primeiro, pontuação de similaridade com código gerado por IA não identifica modelo, versão, provedor nem autor, e qualquer relatório que afirme isso a partir da pontuação está extrapolando. Segundo, código humano moderno escrito com assistentes corporativos produz sinais superpostos, e a base de código legítima da própria organização pode pontuar alto em ferramentas do tipo. Terceiro, atores ofensivos editam saída de modelo e usam ofuscação, o que destrói sinais superficiais e pode virar ausência de pontuação em código assistido. Quarto, o corpus de referência é dinâmico, e a mesma amostra pode pontuar diferente entre versões do toolkit, o que exige registrar a versão usada em cada análise.

A prática recomendada é tratar o resultado como hipótese de proveniência com nível de confiança, no vocabulário do capítulo 5 da biblioteca, e nunca como indicador de autoria. Em relatórios com TLP, o campo deve ser escrito em linguagem calibrada, por exemplo, artefato apresenta múltiplos sinais compatíveis com geração assistida por IA, com confiança moderada, versão do toolkit registrada. Essa calibração protege o analista e a organização de conclusões precipitadas em contexto de atribuição, onde erros têm custo diplomático e jurídico. Quinta limitação prática: a análise em conjunto com campanhas já rotuladas carrega o risco de circularidade, e o analista deve executar o toolkit antes de ler a hipótese anterior sobre o ator, registrando sinais de forma independente, disciplina que a seção de erros desenvolve.

9. Exemplo de Fluxo de Análise

O fluxo abaixo integra o CAIRN à rotina de análise de malware de um time de CTI técnico. O exemplo usa os passos típicos de execução do toolkit sobre um conjunto de amostras de uma mesma campanha, seguido da comparação com o repositório de campanhas anteriores.

Fluxo de análise com CAIRN

1. Coletar artefatos da campanha: scripts, loaders e decompilados legíveis.
2. Registrar proveniência de cada amostra: campanha, data, infraestrutura, TTPs.
3. Executar a análise do toolkit sobre cada artefato, registrando a versão do CAIRN.
4. Capturar para cada amostra: pontuação, sinais ativos e trechos que sustentam os sinais.
5. Comparar a assinatura da campanha com as assinaturas históricas do repositório.
6. Classificar confiança de geração assistida: alta, moderada ou baixa, com justificativa.
7. Publicar no relatório tático o campo de proveniência, com linguagem calibrada.
8. Alimentar a avaliação de capacidade do ator no relatório estratégico.

No passo 6, o critério de confiança deve ser escrito antes da análise, para evitar ajuste de conclusão após o resultado. Uma calibração de exemplo: confiança alta pede alucinação de API confirmada somada a dois ou mais sinais estruturais; confiança moderada pede três ou mais sinais sem alucinação confirmada; confiança baixa cobre o restante, incluindo pontuações altas sustentadas só por formatação. O passo 8 fecha o ciclo com o capítulo 1 da biblioteca, transformando um dado técnico de amostra em inteligência que muda priorização.

10. Posição no Fluxo de Análise de Malware do Capítulo 25

O capítulo 25 da biblioteca organiza a análise de malware em etapas, da triagem à produção de relatório, e o CAIRN ocupa posição específica nesse fluxo, sem substituir nenhuma etapa. O lugar correto é depois da análise estática inicial, quando o artefato já foi identificado, descomprimido e, quando aplicável, decompilado com legibilidade suficiente, e antes da correlação, para que a assinatura de geração entre no conjunto de dados do clustering. Executar a análise antes da deobfuscação desperdiça processamento, porque ofuscação destrói os sinais superficiais que o toolkit observa.

Posição do CAIRN no fluxo do capítulo 25
1. Triagem: identificação de tipo, empacotamento e IOCs brutos.
2. Análise estática: strings, imports, estrutura e decompilação legível.
3. Proveniência assistida: execução do toolkit, pontuação e sinais (esta nota).
4. Análise dinâmica: sandbox, comportamento e configuração extraída.
5. Correlação: clustering com infraestrutura, TTPs e assinatura de geração.
6. Relatório: ATT&CK, IOC, proveniência com confiança e recomendações.

A regra de passagem entre etapas é registrar o resultado da proveniência como campo obrigatório da ficha de amostra, inclusive quando o resultado é ausência de sinais, porque o registro negativo também alimenta a estatística de capacidade do ator. Times que executam o toolkit apenas nos casos que já parecem gerados introduzem viés de seleção no repositório e perdem justamente a dimensão longitudinal que dá valor ao método. O registro negativo, quando documentado, é o que permite ao capítulo 5 recalibrar a avaliação de capacidade sem viés de seleção.

11. Erros Comuns e Pontos de Atenção

Um ponto de atenção adicional é o risco de circularidade na análise. Se o time publica que um ator usa IA e passa a procurar apenas sinais de IA, corre o risco de confirmar a própria hipótese em toda amostra seguinte. O antídoto é manter a análise cega na etapa de execução do toolkit, com o analista registrando sinais antes de ler a hipótese anterior sobre o mesmo ator, disciplina análoga à de hipóteses concorrentes descrita no capítulo 5.

12. Integração com o Restante da Biblioteca

A nota conecta o capítulo 17 ao capítulo 5 no plano metodológico, porque pontuação com confiança e critérios escritos antes da análise são aplicação direta de técnicas analíticas estruturadas e de avaliação de credibilidade. Conecta ao capítulo 9 no plano de ferramentas, ocupando na mesa do analista a posição de instrumento de proveniência, ao lado de plataformas de análise. Com as notas irmãs do capítulo, a Campanha Anthropic fornece o caso que motiva o instrumento, e a FAMOUS CHOLLIMA fornece o vetor de aplicação em portfólios e códigos de candidatos, onde a mesma lógica de sinais ajuda a auditar a proveniência de amostras de trabalho apresentadas em processos seletivos.

Para o leitor que estrutura o time de CTI, a recomendação final é incluir o campo de proveniência assistida por IA no template de análise de amostra da organização, com critério de confiança calibrado e versão de ferramenta registrada. Esse campo, rotineiro e barato, é o que transforma um toolkit de pesquisa em prática de inteligência, e coloca o time na posição de acompanhar a mudança estrutural da produção ofensiva com evidência, e não com impressão.

No recorte do capítulo 25, a nota fornece a etapa de proveniência assistida que passa a integrar o fluxo de análise de malware, com a regra de registro obrigatório, inclusive negativo, desenvolvida na seção 10. O conjunto formado pelo fluxo do capítulo 25, pela confiança calibrada do capítulo 5 e pelo template de amostra da organização é o que consolida a prática, e cada peça reforça as outras na produção do dossiê completo.