CTI.4 - Coleta de Inteligência de Fontes Técnicas

Nota do grupo COL (Ciclo de Inteligência: Planejamento e Coleta) da seção 15 - Framework CTH - Controles.
Deriva do Capítulo 9 do PDF de referência (controle CTI.4) e da fase de coleta do ciclo de CTI da seção 2.8.
Integra honeypots, sandboxes, infraestrutura pública e telemetria interna como fontes de inteligência técnica.

1. Contexto e Posicionamento no Framework CTH

O controle CTI.4 cobre a coleta em fontes técnicas, aquelas que a organização opera ou contrata para observar o adversário diretamente. O Capítulo 9 do Framework CTH destaca um ponto central: a telemetria interna é a única fonte de inteligência exclusiva da organização. Feeds e relatórios estão disponíveis para qualquer comprador, mas os eventos do SIEM, os logs de endpoint e rede e as amostras capturadas refletem os ataques que de fato chegam ao ambiente.

Dentro do ciclo de CTI da seção 2.8, esse controle materializa a coleta técnica que responde aos requisitos derivados dos PIRs (CTI.1) e que complementa o OSINT (CTI.3) com dados primários. O ganho é simétrico: os eventos internos ganham contexto quando correlacionados com inteligência externa, e a inteligência externa é validada quando seus indicadores aparecem, ou não, na telemetria própria. A saída desse controle alimenta diretamente o processamento (CTI.5) e, por meio dele, a análise e o hunting.

2. Inventário de Fontes Técnicas

A tabela a seguir consolida as principais fontes técnicas, se são operadas ou contratadas e o que cada uma entrega ao programa.

A escolha da fonte deve seguir os requisitos de coleta (CRs) da cascata do CTI.1. Honeypot sem pergunta a responder vira passivo de manutenção, e contrato de DNS passivo sem processo de consulta vira linha orçamentária sem uso. O inventário da tabela é o cardápio, não a refeição.

3. Honeypots e Honeynets

Honeypots são sistemas sem função de negócio, implantados deliberadamente para serem atacados. Na interação baixa, emulam serviços e vulnerabilidades conhecidos, capturam varreduras, credenciais padrão e primeiros comandos, com risco e custo de operação reduzidos. Na interação alta, oferecem sistemas reais ou quase reais, registrando a cadeia completa do adversário, do acesso inicial ao movimento lateral, e revelam TTPs que nenhuma emulação antecipa. Honeynets combinam múltiplos honeypots com instrumentação de rede, formando segmento de pesquisa.

O posicionamento seguro é o fator decisivo do projeto. O segmento de honeypot deve ser isolado da rede corporativa, sem qualquer relação de confiança, sem acesso a credenciais reais e com filtragem de egress que impeça o host comprometido de atacar terceiros ou retornar ao ambiente. Todo o tráfego sai apenas para o coletor de logs, e a identificação da infraestrutura pode usar marcas de resolução DNS dedicadas para isolar o tráfego do honeypot no SIEM.

{
  "device": { "hostname": "canary-dmz-01", "ip": "10.66.10.5" },
  "ftp": { "enabled": true, "port": 21 },
  "ssh": { "enabled": true, "port": 22, "version": "SSH-2.0-OpenSSH_8.4p1" },
  "http": { "enabled": true, "port": 8080 },
  "smb": { "enabled": true, "port": 445 },
  "logging": { "syslog": { "enabled": true, "host": "10.66.10.20", "port": 514 } }
}

# Segmento de honeypot 10.66.10.0/24: apenas o coletor de logs recebe saida
iptables -A FORWARD -s 10.66.10.0/24 -d 10.66.10.20 -p udp --dport 514 -j ACCEPT
iptables -A FORWARD -s 10.66.10.0/24 -j DROP
iptables -A FORWARD -d 10.66.10.0/24 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -d 10.66.10.0/24 -j DROP

Os riscos também são conhecidos e gerenciáveis. Um honeypot mal isolado se transforma em pivô para ataques a terceiros, com responsabilidade legal da organização; uma isca descoberta gera tráfego falso deliberado; e a operação exige manutenção, pois serviços emulados desatualizados atraem apenas barulho antigo. Alertar o jurídico sobre a existência do segmento e documentar a finalidade de pesquisa encerra os cuidados básicos.

4. Sandboxes e Repositórios de Malware

A análise automatizada de amostras converte um arquivo opaco em um conjunto estruturado de indicadores e comportamentos. Sandboxes contratadas e públicas executam a amostra em ambiente instrumentado e devolvem hashes, contatos de rede, artefatos de host como mutex e chaves de registro, capturas e sequência de execução; ferramentas de análise próprias, como CAPE, permitem desinfecção de dados antes da submissão e retenção local. Repositórios como MalwareBazaar permitem pesquisar famílias, atores e configurações extraídas.

A saída estruturada do sandbox alimenta o processamento do CTI.5. O trecho abaixo ilustra o formato alvo para uma amostra analisada, já pronto para virar objetos STIX ou atributos na plataforma de CTI.

{
  "amostra": {
    "sha256": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
    "familia_estimada": "loader_comercial",
    "config_extraida": { "c2": ["203.0.113.66:443"], "mutex": "Global\\svc_sync_v7" }
  },
  "ttps_attck": ["T1059.001", "T1053.005", "T1071.001"],
  "fonte": "sandbox_interna",
  "coletado_em_utc": "2025-04-11T14:05:33Z",
  "tlp": "AMBER"
}

Dois cuidados protegem a organização nesse fluxo. Primeiro, nunca submeter amostra com dados confidenciais a sandbox pública, porque a submissão pode vazar contexto estratégico; a sanitização ou o uso de ambiente próprio previne isso. Segundo, considerar o custo de consultas a repositórios terceiros dentro dos limites de taxa, com cache local para hashes já analisados.

5. Certificate Transparency e DNS Passivo

Os logs de Certificate Transparency são uma fonte técnica pública de alto retorno: todo certificado emitido por autoridade participante é registrado, e a consulta por sufixo corporativo revela certificados novos, incluindo os emitidos por atores que montam phishing com domínio semelhante. A consulta periódica é simples e entrega alertas de infraestrutura nova ligada à marca.

curl -s "https://crt.sh/?q=%25.bancoexemplo.com.br&output=json" \
  | jq -r '.[] | [.not_before, .issuer_name, .name_value] | @tsv' \
  | sort -u | tail -n 20

O DNS passivo complementa com a dimensão temporal: registros históricos de resolução permitem responder quais domínios já apontaram para determinado IP, quando um domínio começou a resolver e com quais vizinhos de infraestrutura ele coocorre. Essas perguntas sustentam a triangulação do adversário, ajudam a identificar padrões de registro e de provedor e transformam um IOC único em um cluster de infraestrutura. A combinação com critérios de domínio recém-registrado, idade inferior a dias, alimenta bloqueios preditivos e hipóteses de caça.

6. Telemetria Interna como Fonte Técnica Própria

A telemetria interna (DAT.x) é insumo de detecção, mas também fonte de inteligência em sentido estrito. O CTI.4.1 estabelece canal estruturado entre SOC e CTI: escalonamento de alertas de alta prioridade para análise, reunião semanal de revisão de padrões e mecanismo de SIRs táticos gerados por alertas inexplicados. O CTI.4.2 fecha o circuito contrário, enriquecendo alertas com contexto de inteligência e executando detecções retrospectivas quando novos IOCs chegam às plataformas.

A correlação semanal do CTI.4.4 analisa três conjuntos: IOCs externos observados internamente, padrões internos que correspondem a campanhas conhecidas e eventos internos sem correspondência externa, estes últimos potencialmente indicativos de adversário desconhecido. O fluxo abaixo é a versão prática desse controle.

1. Exportar da plataforma de CTI os indicadores da semana, com fonte, TLP e confiança.
2. Executar busca retrospectiva nos logs retidos, com janela compatível com a retenção (DAT.5).
3. Registrar correspondências, avaliar contexto de ator e atualizar o perfil de ameaça (CTI.2).
4. Escalar para hunting os padrões internos sem correspondência externa.

A consulta a seguir exemplifica a busca retrospectiva por IPs de C2 recém-publicados.

DeviceNetworkEvents
| where Timestamp > ago(30d)
| where RemoteIP in ("203.0.113.66", "198.51.100.23")
| project Timestamp, DeviceName, RemoteIP, RemotePort,
          InitiatingProcessFileName, InitiatingProcessCommandLine
| order by Timestamp asc

O CTI.4.5 eleva a telemetria a fonte proativa: análise de anomalias identifica comportamentos que não casam com assinatura alguma, e esses padrões geram hipóteses de hunting e novas requisições de coleta. É a materialização de que a organização pode descobrir adversários que ainda não existem em nenhum relatório público.

7. Automação de Coleta via APIs

Toda a coleta técnica se automática via APIs, com três exigências de engenharia: formatos padronizados de saída, tipicamente JSON; agendamento com janelas definidas; e respeito a limites de taxa, com cache e recuo exponencial. O padrão abaixo cobre a maioria dos casos e se integra ao pipeline do CTI.5.

import requests, time

def coletar_com_resiliencia(url, params=None, tentativas=5):
    for i in range(tentativas):
        try:
            r = requests.get(url, params=params, timeout=30)
            if r.status_code == 429:
                time.sleep(2 ** i)
                continue
            r.raise_for_status()
            return r.json()
        except requests.RequestException:
            time.sleep(2 ** i)
    raise RuntimeError(f"Falha na coleta de {url} apos {tentativas} tentativas")

As chaves de acesso devem residir em cofre, cada fonte deve ter métricas de execução, volume e erro, e a falha silenciosa precisa ser tratada como incidente de pipeline. Um feed que parou de atualizar sem alerta é fonte falsa de confiança, pior do que fonte ausente, porque a ausência de IOC novo passa a parecer segurança quando é apenas defeito.

8. Triangulação Técnica

A triangulação técnica aplica ao plano da infraestrutura o que a triangulação de fontes aplica às alegações: nenhum indicador entra em bloqueio ou em relatório com uma única confirmação. O mesmo IP pode aparecer em reputação, em DNS passivo, em telemetria interna e em nota de sandbox, e cada fonte confirma um aspecto diferente, como atividade, histórico e associação a família ou ator.

Divergências entre fontes são informação, não incômodo. Um IP atrás de CDN apresenta reputação herdada; um domínio com registro recente e reputação limpa pode ser o descarte frio típico de campanha dirigida. O analista registra as discrepâncias e as usa para ajustar confiança no processamento (CTI.5) e para calibrar o peso de cada fonte no catálogo (PLT.4).

9. Implementação Prática e Salvaguardas por Nível

O Framework CTH organiza o controle em cinco salvaguardas progressivas, resumidas na tabela a seguir.

A implantação começa pelo canal e pelo circuito de alertas, que exigem processo mais do que ferramenta. Sandboxes e repositórios entram na sequência, com sanitização e cache; honeypots só devem ser implantados com segmento isolado, filtragem de egress e coletor dedicado, e sua expansão para honeynet só se justifica quando a análise do que foi capturado já está funcionando.

10. Erros Comuns e Pontos de Atenção

• Honeypot mal isolado virando pivô: sem filtragem de egress e sem segmentação, o sistema isca se transforma em plataforma de ataque, com dano a terceiros e exposição legal.
• Confiança em sandbox única: comportamentos divergem por configuração e por evasão; análise cruzada entre ambientes e com repositórios evita conclusão distorcida.
• Submissão sem sanitização: amostras com documentos e credenciais da organização revelam contexto estratégico em serviços públicos.
• Telemetria interna ignorada: tratar o SIEM como fonte só de alertas desperdiça a perspectiva exclusiva que o controle considera a mais valiosa de todas.
• Retro-hunting nunca executado: IOCs novos que chegam às plataformas sem busca retrospectiva nos logs deixam de revelar períodos anteriores de comprometimento.
• Coleta sem processamento: dados técnicos brutos acumulados sem o pipeline do CTI.5 não viram inteligência, viram arquivo morto com custo de armazenamento.

A correção estrutural para todos os itens é processual: fonte técnica só entra no catálogo com requisito associado, isolamento revisado, roteiro de sanitização e destino definido no pipeline. O valor da coleta técnica está na corrente completa, do evento capturado ao produto de inteligência que muda uma detecção ou uma prioridade.

11. Integração com Outros Controles do Framework CTH

A coleta técnica madura fecha o circuito que o grupo COL propõe: requisitos definem a coleta, a coleta alimenta o processamento e o resultado retorna ao perfil de ameaças e às detecções. Quando o circuito funciona, cada nova infraestrutura de adversário observada em honeypot, sandbox ou telemetria própria se converte em vantagem concreta no prazo de um ciclo.