Vulnerability e Exploit Intelligence

Nota do capítulo 05 (Análise e Produção de Inteligência).
Cobre as fontes de inteligência de vulnerabilidades e exploits, o ciclo de vida do exploit desde a disclosure até os kits, os indicadores de exploração ativa e a relação com EPSS e KEV.
Dialoga com a Análise Bayesiana Aplicada à CTI, com o capítulo 03 de indicadores e com o EASM da biblioteca.

1. Contexto e Posicionamento na Biblioteca

Inteligência de vulnerabilidades e de exploits é o segmento de CTI com o consumidor mais claro e o retorno mais mensurável: a equipe de vulnerabilidades precisa decidir, todos os dias, quais milhares de CVEs publicadas merecem atenção, e a decisão melhora quando entrada de inteligência substitui severidade nominal por risco real de exploração. A distinção central da nota é entre a vulnerabilidade, que é uma propriedade do software e se descreve com CVE e CVSS, e o exploit, que é um artefato do adversário com ciclo de vida próprio, atores que o produzem, mercados onde circula e assinaturas observáveis. Vulnerability intelligence monitora a primeira; exploit intelligence monitora a segunda, e é a segunda que define urgência.

A nota se apoia na trinca analítica do capítulo: o posterior de exploração da nota bayesiana é o produto formal desta avaliação, os critérios escritos são contramedida aos vieses de disponibilidade e ancoragem que dominam decisões de patching. Para baixo, a nota alimenta o gerenciamento de vulnerabilidades, o virtual patching no WAF, as regras de detecção da engenharia de detecção e o inventário de exposição do capítulo de EASM, que responde à pergunta decisiva: o produto vulnerável está exposto no nosso ambiente e em qual superfície.

2. Fontes: do CVE ao Mercado de Exploits

As fontes se organizam em camadas, da formal à clandestina, e cada camada entrega uma parte do quadro com latência e confiabilidade diferentes. Nenhuma camada basta sozinha, porque a formal é lenta e seca e a clandestina é ruidosa e mentirosa, e a função do analista é triangulá-las com rastro de proveniência.

A leitura inteligente das camadas segue a pergunta de decisão. Para saber se o produto afetado existe no ambiente, o registro formal e o inventário bastam; para saber se vale patching emergencial, o advisory de vendor e o KEV dominam; para entender se a exploração em curso tem assinatura observável, o advisory do vendor e a comunidade técnica entregam os IOCs de tentativa; para antecipar escalada, a camada de mercado fornece o sinal mais cedo e o mais barulhento. O advisory do vendor merece leitura fina porque entrega o que ninguém mais tem: as condições exatas de exploração, como a sequência de eventos do Log4Shell exigia a expansão da string de lookup no log, e esses detalhes viram detecção, e não apenas lista de versão corrigida.

Dois detalhes de processo ajudam a ler as fontes formais com expectativa correta. O ID de CVE é um identificador de reserva de escopo, e não uma avaliação: a reserva é feita por um CNA, que pode ser o próprio vendor, e a descrição e a pontuação chegam depois, às vezes com semanas de defasagem, e às vezes são revisadas, como os casos de atualização de escopo de produtos afetados demonstram. A prática segura é monitorar o advisory do CNA e do vendor como fonte primária, usar o registro formal como âncora de identificação e registrar a data de cada consulta, porque o enriquecimento de hoje não é o de daqui a duas semanas.

O sinal de mercado, apesar de barulhento, tem valor quando coletado com disciplina mínima, e a rotina recomendada para CVEs críticas de perímetro inclui os itens abaixo.

• Monitorar repositórios e perfis de pesquisa com alerta por nome do produto e por padrão do endpoint afetado, que é onde o PoC costuma aparecer primeiro.
• Acompanhar anúncios de venda e de licenciamento de exploit em fóruns e canais fechados, com foco em existência e maturidade, e não em preço exato.
• Registrar a primeira aparição do padrão de exploração em honeypots próprios ou em feeds de telemetria, que costuma ser o marco de transição para varredura em volume.
• Comparar o rótulo de exploração em campo do vendor com evidência técnica própria antes de propagar a afirmação para fora da equipe.

3. Ciclo de Vida do Exploit

O exploit é um artefato que nasce, matura e circula, e as oportunidades de detecção mudam de fase em fase. O ciclo padrão começa com a pesquisa, quando o bug existe em segredo na posse do pesquisador ou do comprador; passa pela disclosure, coordenada ou não, quando o bug ganha ID de CVE; pela publicação de PoC, quando o conhecimento se torna reprodutível; pela weaponização, quando o PoC vira ferramenta confiável com evasão e persistência; pela integração em kits e bots de varredura, quando a barreira de habilidade despenca; e pela exaustão, quando o patch massivo torna o alvo escasso e o exploit muda de mão para campanhas de baixo volume contra a cauda de sistemas não corrigidos.

A leitura operacional da tabela é que cada fase tem um consumidor diferente da inteligência. O time de vulnerabilidades consome disclosure e PoC para iniciar inventário e patch, o time de detecção consome PoC e weaponização para escrever regras de tentativa, o time de rede e WAF consome a integração em kit para virtual patching em escala, e o CTI monitora o mercado desde a pesquisa, porque o sinal de preço e de demanda antecipa o que a formal não mostrará por semanas. Definir quem consome cada fase é o que transforma a tabela em fluxo, e não em taxonomia decorativa.

Casos públicos calibram a sensação de tempo. Na CVE-2021-44228, o Log4Shell, a disclosure e o PoC aconteceram praticamente no mesmo dia, e a varredura massiva seguiu em horas, comprimindo a janela de decisão a menos de um ciclo de change management. Na CVE-2024-3400, do appliance de firewall de acesso remoto, a exploração em campo precedeu a correção, e o caso entrou no KEV, ilustrando a fase mais delicada do ciclo: a exploração dirigida durante a janela em que o patch ainda não existe. O aprendizado operacional é que a fase de PoC é o pivô: antes dela, a urgência é potencial; depois dela, com kit integrado, a urgência é imediata para qualquer superfície exposta.

4. Indicadores de Exploração Ativa e o Papel de EPSS e KEV

Indicador de exploração ativa é a evidência observável de que alguém está tentando ou conseguiu explorar a CVE, e ele vive em três planos. No plano externo, honeypots, telemetria de ISPs e feeds do vendor revelam padrões de varredura e payloads de tentativa, como as strings de probe do Log4Shell nos headers HTTP. No plano do perímetro, o WAF, o proxy e os logs de aplicação revelam tentativas específicas contra o próprio ambiente, que são a evidência mais valiosa porque significam que o adversário já achou a porta. No plano interno, o EDR e os logs de processo revelam a pós-exploração, como spawn de shell por processo de serviço web, que é o sinal de que a tentativa virou acesso.

A consulta ao EPSS é rotina de enriquecimento e pode ser automatizada por API, e o trecho abaixo mostra a chamada direta ao serviço público.

curl -s "https://api.first.org/data/v1/epss?cve=CVE-2024-3400&pretty=true"

A resposta retorna a pontuação corrente, que representa a probabilidade de a CVE ser explorada em campo nos próximos trinta dias, e a série histórica com o parâmetro de histórico. O KEV entrega uma informação diferente em natureza: não é probabilidade, é confirmação, porque a agência só inclui CVE que comprovadamente foi explorada em ataques reais. A leitura correta é hierárquica: KEV presente significa exploração já confirmada no mundo, EPSS alto significa expectativa de exploração, e CVSS alto sozinho significa apenas gravidade teórica, e essa hierarquia é a base da avaliação da seção final. A tabela abaixo consolida a comparação entre os três recursos que dominam a fila de decisão.

A consulta abaixo exemplifica a busca por tentativas de Log4Shell na telemetria de rede, com o formato de payload característico.

DeviceNetworkEvents
| where Timestamp > ago(7d)
| where RemoteUrl has "${jndi:" or AdditionalFields has "${jndi:"
| summarize tentativas = count(), hosts_unicos = dcount(RemoteUrl)
    by bin(Timestamp, 1h), RemoteIp
| order by tentativas desc

5. Inteligência de Patches e Janela de Risco

A janela de risco é o intervalo entre a disclosure da vulnerabilidade e a aplicação efetiva da correção no ambiente, e é dentro dela que a organização aposta. A análise de inteligência de patches acompanha três subintervalos: o tempo entre disclosure e patch disponível, que idealmente é zero mas não é, como os casos de exploração pré-patch demonstram; o tempo entre patch disponível e decisão de instalar, que é dominado por testes e dependências; e o tempo entre decisão e aplicação efetiva em todos os ativos, que é dominado pela cauda de sistemas difíceis. O exploit intelligence informa esse cálculo de forma direta: quanto mais avançada a fase do ciclo do exploit, mais a janela precisa encolher, e a ferramenta de encolhimento é o virtual patching, as regras de WAF e a exposição reduzida enquanto o patch institucional avança.

O registro didático abaixo ilustra o cálculo com um caso inspirado no ritmo de CVE-2024-3400, com datas ajustadas para fins de exemplo.

A leitura da tabela dá o perfil do risco. A janela de risco total foi de sete dias, mas a sobreposição entre exploração massiva e ambiente não corrigido foi de três dias, e é essa sobreposição que a inteligência tenta antecipar. O ganho de cada dia arrancado da janela é mensurável, e a prática madura registra por evento as datas de cada marco, porque a série histórica é o que permite justificar investimento em virtual patching, testes de patch acelerados e redução de exposição permanente, que são as três alavancas reais da janela.

O virtual patching merece nota técnica porque é a única alavanca que atua no intervalo sem tocar o ativo. A regra de WAF que filtra o padrão de exploração, a restrição de acesso ao endpoint vulnerável e a desativação do recurso afetado, quando o advisory prevê workaround, todas encurtam a exposição sem esperar o ciclo de teste do patch, e cada uma tem custo próprio de falso positivo que precisa ser monitorado. A prática disciplinada registra a regra com data de expiração vinculada à aplicação do patch real, porque virtual patching esquecido vira dívida técnica silenciosa que esconde a superfície real do ambiente.

6. Exemplo de Avaliação de CVE Nova

Uma CVE nova é publicada afetando um gateway de acesso remoto usado por duas filiais, e a avaliação segue o roteiro desta biblioteca em seis passos, cada um com fonte e decisão associada.

• Identificar o escopo interno: consultar o inventário e o EASM para responder se o produto e a versão afetada existem no ambiente e onde; sem essa resposta, o resto da avaliação é acadêmico.
• Ler o advisory do vendor com atenção às condições: quais configurações habilitam o bug, quais versões corrigem, se há workaround e se o vendor reporta exploração em campo, porque a palavra explorada do PSIRT muda tudo.
• Consultar KEV e EPSS: presença no KEV indica exploração confirmada, e EPSS alto indica expectativa quantitativa, e ambos alimentam o prior da análise bayesiana da nota anterior.
• Verificar PoC e maturidade na comunidade: existe PoC funcional, ele exige autenticação ou não, já apareceu em kit ou bot de varredura, e a resposta define a fase do ciclo em que a CVE está.
• Definir a fase e a ação: com produto exposto e PoC público, a decisão típica é patching emergencial ou virtual patching imediato, e com produto apenas interno e sem PoC, a decisão é patch na janela ordinária com monitoração de signposts.
• Registrar o signpost de escalada: entrar no radar os gatilhos que mudariam a decisão, como aparição em kit, bloco de varredura massiva e reporte de exploração por CSIRT, com dono e gatilho de ação, conforme a nota de Indicators and Signposts.

O produto da avaliação cabe em um registro curto, e o formato abaixo é o padrão desta biblioteca para o artefato de decisão de CVE.

avaliacao_cve:
  id: CVE-2024-XXXXX
  produto_interno: gateway de acesso remoto, 2 instancias em filiais
  exposicao_externa: parcial, uma instancia em URL publicada
  advisory:
    condicao_exploracao: requisicao não autenticada ao endpoint de VPN
    workaround_disponivel: desabilitar recurso secundario ate o patch
    vendor_reporta_exploracao: sim
  quantitativo:
    kev: sim
    epss_corrente: 0,93
  fase_ciclo_exploit: weaponizacao, sem integracao a kit observada
  posterior_30d: 0,94 (quase certo), prior de taxa base + KEV + EPSS + PoC
  decisao: patching emergencial em 48h, virtual patching no WAF imediato
  signposts:
    - aparição em kit de exploração: ampliar varredura para toda a base
    - reporte de CSIRT nacional: comunicar filiais e revisar logs de 90 dias

A leitura do registro mostra o encadeamento que a avaliação quer forçar: escopo antes de gravidade, confirmação antes de probabilidade e fase do ciclo antes de calendário. O posterior de 0,94 não é um número solto, é o produto de um prior de taxa base corrigido por evidências em ordem de força, e a decisão de 48 horas é derivada da exposição externa da instância, e não da severidade nominal da CVE. O mesmo formato serve para a decisão inversa, de não priorizar, porque o registro mostra exatamente quais evidências estavam ausentes quando a fila ficou cheia.

7. Erros Comuns e Pontos de Atenção

• Priorizar por CVSS isolado: severidade teórica não é risco de exploração, e a pilha CVSS alta sem exposição e sem exploit perde para CVSS médio com KEV, PoC público e ativo exposto na internet.
• Tratar EPSS como verdade: a pontuação é uma estimativa diária de probabilidade, sensível a ruído e a picos, e precisa ser consumida com data e contexto, e não como etiqueta permanente.
• Confundir presença no KEV com obrigação universal: o catálogo orienta o mandato de agência estadunidense, mas a prática de mercado adota o mesmo por ser proxy de exploração real, e a adesão precisa ser decisão interna consciente.
• Ler o advisory só pela lista de versões: as condições de exploração descritas no texto do advisory são matéria-prima de detecção, e pular o texto perde o IOC e a assinatura que o vendor já entregou.
• Copiar PoC para o ambiente produtivo de análise: PoC público é malicioso até prova em contrário, e a execução exige ambiente isolado, porque builds distribuídos em repositórios já foram vistos com carga extra.
• Fechar a janela só com patch: o patch institucional tem lead time, e a equipe que não combina patch com virtual patching, restrição de exposição e detecção de tentativa fica exposta no intervalo que importa.
• Ignorar a cauda do ciclo: depois do boom de varredura, a exploração da cauda de sistemas não corrigidos continua por meses, e o relatório de exposição precisa rastrear o patch pendente até zerar.
• Desconsiderar a cadeia de exposição: a CVE afeta componente de terceiro dentro de produto próprio, e avaliar só o fornecedor principal deixa o risco real invisível no inventário.
• Automatizar bloqueio por IOC de tentativa sem janela: os padrões de varredura circulam entre infraestruturas descartáveis, e bloqueio sem expiração e sem revisão infla regras que nenhum painel sustenta.
• Avaliar a CVE pelo noticiário: a cobertura de imprensa antecipa o pior caso, e a decisão que nasce de manchete, em vez de advisory, KEV e inventário, entrega a janela de patching inteira ao viés de disponibilidade.

8. Integração com o Restante da Biblioteca

Esta nota converte o repertório analítico do capítulo 05 em um fluxo de decisão operacional: o posterior de exploração da nota bayesiana é o produto formal da avaliação, os signposts da nota de SATs são o mecanismo de reabertura da decisão e os critérios escritos são a contramedida aos vieses que distorcem patching. Para baixo, a nota se conecta com o inventário e a superfície do capítulo de EASM, porque o escopo interno é o primeiro passo da avaliação, e com as notas de indicadores do capítulo 03, porque os padrões de tentativa viram IOAs com prazo de validade curto e descarte disciplinado.

Um hábito que fecha o ciclo analítico do capítulo é registrar cada avaliação de CVE nova no mesmo repositório das anteriores, porque a série histórica de avaliações comparadas aos resultados reais é a única calibração possível para os julgamentos de verossimilhança que sustentam os posteriores de exploração. Sem esse repositório, cada CVE nova é avaliada com a mesma confiança não examinada da anterior, e a equipe nunca descobre se o próprio processo de priorização acerta mais do que o sorteio.

No framework da seção 15, o fluxo desta nota alimenta o CTI.4 de coleta técnica, com as fontes de advisory e de risco quantitativo, e o INS.4 de monitoramento de exposição, onde a pergunta de escopo é respondida continuamente. A cadeia completa, do advisory do vendor ao posterior de exploração e à regra de WAF, é também o exemplo canônico de valor de CTI mensurável: a métrica de janela de risco fechada antes da exploração massiva aparece no capítulo de métricas como resultado, e não como narrativa.